リーダビリティ (Google) : コードレビューを通じての標準化されたメンター制度
標準化されたものだが、人間主導のプロセス
リーダビリティが扱うもの
プログラミング言語のイディオム
コード構造
API 設計
共通ライブラリーの適切な利用
ドキュメンテーション
テストのカバレッジ（coverage：対象範囲）
その他各種の広範囲な専門知識
リーダビリティプロセス
全てのチェンジリスト (changelist/CL) にはリーダビリティ承認 (readability approval) が必要
リーダビリティ承認は、そのプログラミング言語のリーダビリティ認定 (readability certification) を保持している者がその CL を承認したことを示す
認定を受けているコード作者は、自分自身のCLに対して暗黙のリーダビリティ承認を出している扱い
リーダビリティレビュアーは、Google のエンジニアのうちの約 1 ～ 2 % (リーダビリティがある人の中からボランティアでなる)
コード作成者は、リーダビリティのガイドラインを徐々に身につけていき、CL で受けるコメントが少なくなっていく
ついにはリーダビリティプロセスから卒業し、正式にリーダビリティを授与される
リーダビリティプロセスの利点
主要なものとして、所属チームの組織慣習的知識のみならず、それ以上のものにエンジニアたちが触れられること
あるプログラミング言語でのリーダビリティを獲得するには、まずエンジニアはCLを送る
そして、全社中のコードをレビューするリーダビリティレビュアーから成る中央集権的な集団が行うレビューを経なければならない
このプロセスを中央集権的とすることによる重要なトレードオフ
組織の発展に伴って劣線形ではなく線形にスケールする形に限定されている
この限定により次のことが容易になる : 一貫性の強制、情報の孤島化の回避、確立された標準からの（多くの場合意図的でない）逸脱の回避
大規模変更の作者（22章参照）にとっては、何千ものチームの境界を越えたモノリポ全体にわたる変更の実行が容易
チームを異動しても、同じプログラミング言語の利用法は元のチームでの利用法と極端に変わるわけではないという確信を持てる
コストは無視できない
リーダビリティのあるチームメンバーがいないチームの手間が増大する
など
リーダビリティプロセスに実施するだけの価値はあるか？
リーダビリティプロセスは物議をかもすもの : トレードオフを取るだけの価値はあるか？
リーダビリティはエンジニアリングの速度に対し総じて良い影響を与えることが示された
リーダビリティのあるコード作者によるCLには、リーダビリティのないコード作者によるCLと比べ、レビューならびにリポジトリーへの提出の際に、統計的に有意に少ない時間しかかからない
参考文献